There are many existing mechanisms and devices that can enforce security policies at the network level in different points of the network or the computer system stack. These include network equipment such as routers, firewalls, Intrusion Prevention Systems (IPS), as well as software components running in operating systems, hypervisors, and virtual machines. Examples include Linux IP tables, Linux open vSwitch, Microsoft Windows Firewall, VMware NSX distributed firewall, etc. In addition, public and private cloud service providers—those who own and provide the hardware, network connections, underlying software, and other services to support running of third party application programs on virtual machines or in containers and the like—offer APIs to configure their virtual firewalls that enforce network communication for their virtual machines and container instances. Examples include Amazon® security groups and OpenStack® security groups. These mechanisms operate at the network level and are configured with rules specifying network elements. The phrase “cloud-native controls” will refer to built-in security controls offered by public and private cloud service providers.
A network security enforcement mechanism—typically implemented as a process performed by a computer under the control of stored software instructions, but also in hardware configured by software—intercepts network traffic at a given point along the traffic's communication path and checks the traffic against a set of network security rules. A network security rule is usually specified by a set of matching conditions and an action. Every packet processed by the enforcement mechanism may be checked against all the security rules. If the conditions specified in a rule is satisfied by the packet, the rule is said to match the packet. In general, more than one rule can match a packet. In this case a priority mechanism is used to select one of the matching rules and the action specified by the higher priority rule is applied to the packet.
Many different types of actions can be specified in a rule, two of which are allow and block. An “allow” rule allows the packet to continue on its path to its destination and a “block” rule discards the packet. Matching conditions of a rule can specify a set of conditions that common fields in a network packet should satisfy. These conditions may specify a value, a range of values, or a prefix that a packet field must satisfy. Packet fields commonly used in network security rules include: the IP protocol number in the packet IP header field; the destination IP address in the packet IP header field; the source IP address in the packet IP header field; the destination port number in the TCP or UDP header if the IP protocol is TCP or UDP; and the source port number in the TCP or UDP header if the IP protocol is TCP or UDP. Some network security mechanisms also use other packet fields such as layer2 MAC addresses, frame type, and VLAN id. They can also use metadata information that is not present in the packet data but can be extracted from the network processing environment such as for example the port in which the packet was received on a multiport device such as a network switch.
Different network security enforcement mechanisms offer different capabilities. Some enforcement mechanisms may not support both types of rule actions. For example, Amazon AWS security groups only support “allow” actions, and do not support “block” actions. Enforcement mechanisms differ in the degree of isolation from the workload unit. Enforcement mechanisms implemented at the operating system level are more susceptible to security threats that exploit vulnerabilities of applications running on the same operating system. If a threat is able to gain root access in an operating system it can disable the security rules of the enforcement mechanism. Enforcement mechanisms implemented outside the operating system are in a different security domain and are much less vulnerable to these threats. Among these, enforcement mechanisms implemented in separate devices, such as network firewall and switches, offer the lowest degree of vulnerability. A network security enforcement mechanism can offer one of several possible degrees of isolation in increasing order of isolation: same software domain as the workload unit; different software domain; different hardware domain.
Some enforcement mechanisms may be configured to generate a notification when a packet is discarded because it violates the network security policy. In general security mechanisms implemented in operating systems and hypervisors can be instrumented or programmed to generate these notifications. Network devices such as firewall and cloud network security API's usually do not offer this capability. Some enforcement mechanisms implemented at the operating systems can support matching rules that specify a particular application program. Some enforcement mechanisms have a maximum number of rules that be configured. Enforcement mechanisms in public cloud providers are examples of these mechanisms.
A network switch is not able, for example, to enforce policy rules on network packets sent between two virtual machines hosted in the same hypervisor, since these packets are not processed by the network switch. Physical network switches do not process packets exchanged between virtual machines hosted in the same physical server. Enforcement mechanisms implemented in an operating system will be able to intercept more traffic between applications running. Similarly, network security enforcement mechanisms implemented in a hypervisor and mechanisms offered by cloud service providers can intercept traffic between guest machines.